Ian & Stuart's Australian Mac 1993 September

home *** CD-ROM | disk | FTP | other *** search

/ Ian & Stuart's Australian Mac 1993 September / September 93.iso / Community / BBS / BBS Networks / Fidonet / FidoNews 1023 < prev next >

Wrap

Text File | 1993-06-07 | 42.6 KB | 904 lines | [TEXT/R*ch]

F I D O N E W S -- Vol.10 No.23 (07-Jun-1993) +----------------------------+-----------------------------------------+ | A newsletter of the | | | FidoNet BBS community | Published by: | | _ | | | / \ | "FidoNews" BBS | | /|oo \ | +1-519-570-4176 1:1/23 | | (_| /_) | | | _`@/_ \ _ | Editors: | | | | \ \\ | Sylvia Maxwell 1:221/194 | | | (*) | \ )) | Donald Tees 1:221/192 | | |__U__| / \// | Tim Pozar 1:125/555 | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+-----------------------------------------+ | Submission address: editors 1:1/23 | +----------------------------------------------------------------------+ | Internet addresses: | | | | Sylvia -- max@exlibris.tdkcs.waterloo.on.ca | | Donald -- donald@exlibris.tdkcs.waterloo.on.ca | | Tim -- pozar@kumr.lns.com | | Both Don & Sylvia (submission address) | | editor@exlibris.tdkcs.waterloo.on.ca | +----------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies and other boring but important details, | | please refer to the end of this file. | +----------------------------------------------------------------------+ ======================================================================== Table of Contents ======================================================================== 1. Editorial..................................................... 2 2. Articles...................................................... 2 Not *THIS* BBS!............................................. 2 A Programmer's Nightlife.................................... 4 Connecting 9600 and beyond.................................. 5 New Echo: The Complaint Department.......................... 12 Time to do away with Zone Mail Hour......................... 13 New Echo: Bartering: North and Central New Jersey........... 14 A Star Trek computer network................................ 14 3. Fidonews Information.......................................... 15 FidoNews 10-23 Page: 2 07 Jun 1993 ======================================================================== Editorial ======================================================================== You would think, after twenty or so years in the business, that it would be possible to get a system written on schedule. Everything would be tested beyond belief; all the hardware would get installed and tested on time, and you could simply walk in the door with three of four megs of code, plug it in, and collect the admiring stares. (And the cheque, of course). Some day, I swear, it is going to happen. We have a biggy system going in Tuesday. It is now Sunday, two in the afternoon, and I have been hammering away at code for seven hours so far today. Nearly everything works. (We think). The system is to be installed on a radio packet switched network spread out over eight or nine hundred acres, and the hardware guys swear that the computers are all working. When I fired everything up on thursday, only one station managed to connect. They say that thay have found the problem and things will be ready. Ok. we'll believe you, though thousands would not. When we asked one machine to test some traffic lights, it turned on the red light first. Outside, the green light came on. Then we tried the green light. The red light came on. Mmm. Should be kind of amusing when we get twenty or so off-road hundred-thousand-kilo trucks obeying the signs. I think walking the ground with a set of walky-talkies might be in order. It will get us away from the keyboard anyway. (Someday I will tell you about burying one of those trucks under about one-half-million pounds of crushed stone. I *did* ask the driver to get out first, but I do not think I will ever live it down. Real-time testing is *such* fun). Anyway, it is time to get the snooze out the door. Break time is over. Hello world. ======================================================================== Articles ======================================================================== Not *THIS* BBS! by Steve Lamb 1:203/1369 This is partly in response to Terry Bowden's short article from fido1021.nws regarding "Sensible BBS names in the Nodelist" and is to some assumptions about Fido-Net as a whole. Terry's article is just the catalyst that got me to write this article. >Now the nodelist is a listing of bulletin board systems, right? Wrong. My system as of three weeks ago ceased it's BBS function and went mail-only. He is also forgetting that administration nodes need not be BBS nodes. The nodelist is a list of NODES. Whether a BBS is there are not is not part of the *NODE*list. FidoNews 10-23 Page: 3 07 Jun 1993 >And every entry is a BBS, let's face it. Except for mail-only and Admin nodes. >list a newcomer as The_Lantern_BBS, I generally suggest that >"_BBS" is not necessary. Then again, do you really need "The_" To this, however, I *DO* agree! >May I suggest that users and coordinators take this approach? Again, I agree. But the problem here is the assuption that ALL systems in the nodelist are BBSs. Last time I checked the ONLY requirement to be listed in the Fido-Net nodelist was to have an operational mailer running during Zone Mail Hour. A mailer that can send and receive netmail. Nothing about BBSs. I hit this problem face first a few weeks ago when I decided that after two years of running my BBS, the Abcb Cafe, I was going to take it down. However, I was going to leave my mailer running from midnight to 5am to send/receive the Fido-Net Echomail and Netmail that I, personally, wished to participate in. Three weeks now and I'm still getting constant unsolicited netmails to me because I am a "System Operator", SysOp. I'M NOT! Three weeks now and I still cannot hand out this phone number to my friends and family to call because constantly during the day the phone rings. For the past week there has not been one single human caller, it's all been mailers! The former callers of my BBS have gotten the point, when will the rest of the net? And this is a problem. The rules and regulations in Fido-Net are quickly carrying it away from an amateur network. I agree with many things most people say about cutting down the size of the nodelist. Let's remove redundant technical flags.. Face it, you cannot have v32b w/o v32 so why have both? Or even v22, v22b and so on? But there are a few flags I think should be left in for one reason. ALL SYSTEMS IN FIDO-NET ARE NOT BBSs! Because of that reason, not all of us are up 24 hours a day to receive mail. We meet the minimum requirements and just want to get our mail and be left alone. For those of us who want this, what is wrong with the -PVT- flag and -Unpublished- for the phone number? Because I do not run a BBS, which is not a requirement for Fido-Net, I don't WANT people netmailing me at 2pm when my friends and family may call. I don't WANT people to know my phone number. I can have it unpublished in the phone book, why not Fido? Some will say, why not then become a point? Pun intended, being a point is NOT the point. I meet the requirements, correct? Now, ever try to start an echo as a point and HUB the mail for that echo for other nodes when you're a point. I thought so. FidoNews 10-23 Page: 4 07 Jun 1993 At least when you are unpublished there are established routes to get netmail to you. Once they get there all it takes is for them to enter the phone number for your node. For a point it's an extra step, they aren't in the nodelist, they are dependant on their bossnode who may go down at any time and never return, and for the nodes the point HUBs they have to create a new nodelist! It all comes down to this, why do people in Fido-Net assume that every node in the nodelist is a BBS? And why do we alienate people who meet the minimum requirements of Fido-Net who have something to contribute? Is that, I ask, the attitude of an amateur network? ---------------------------------------------------------------------- A Programmer's Nightlife Hank Tassin Navel Lint 1:3800/6.9 Sleep... What is it? Do our minds need it, do our bodies need it, or both? Or neither, we just THINK we do? Rest is one thing, although that may not be enough to hold together that gooey mess we call a brain. REM sleep may be a diversion, it may be the recharging of the electro-chemical processors in that gray matter we hold to be the keeper of life itself. For that matter, REM sleep could be the DIScharging of same, with the day's activities serving to charge it up, when after a full day, you risk overcharging. The results would be the same, the electro-chemical potential between one synapse and another would be reduced to low levels lowering the flow. Wiped out I was yesterday, but was able to hang on until the kiddies went to bed. Hit the pillow around 8:45pm, and took all of about 3 minutes to reach that oblivious state we cherish. Wouldn't you know, 2:30am rolls around and my eyes spring open as if I had gotten all the REM and rest I needed, so now it was time to do some serious coding in Fox. (last thing I remembered the night before was thinking about the program) I get up, light up a smoke, put on a pot of coffee, and jump in the shower. Well, I musta showered in record time cause it was only 12:30am when I got out! It doesn't matter though, cause I'm up in one of those rare instances when I know laying back down in bed won't bring the comforting blackness again. That's why the questions now.... what's it all about? Stay well -Hank FidoNews 10-23 Page: 5 07 Jun 1993 Connecting 9600 and beyond CONNECTING 9600 AND BEYOND --------------------------- By Chip Morrow - 1:226/1400 * Note to Fidonews readers - I am not an expert in high-speed data communications. I ran a multi-node BBS for years however, and received lots of questions about 9600+ from my users. This article was thrown together and posted for the people on my BBS, based on my few years of experience with USR HST and low-end v.32bis modems (I'm a cheapskate). I tried to use layman's terms wherever possible. I'm sure you won't agree with some of this. That's ok. I don't expect you to. If you CAN use any of this, or want to imbellish some or all of it for use elsewhere (a bulletin on your own BBS, a liner for your birdcage), that's ok too. Now that I'm getting out of the BBS business, and this bulletin won't be available on my own board anymore, I thought I'd share it with anyone interested. Free advice, and "For what it's worth" department: I have been asked about 9600 BPS and beyond, transfer speeds, and configuration settings more times than I care to think about, so the time has come to sit down and write a bit on this subject. In fact, I've had to update this file at least two or three times now. If you are the least bit interested in upgrading to 9600 or 14400+ BPS, (or maybe you just bought one and want some real-life information), you might find this interesting. Then again.... maybe not! <grin> First some standard terminology: BPS = Bits per second. A "2400" modem travels at 2400 bps. CPS = Characters per second. A "2400" modem travels at about 240 cps. MNP = Microcom Networking Protocol (hardware error correction). MNP-5 = Microcom Networking Protocol (hardware data compression). V32 = The CCITT standard for 9600 BPS operation. V32.bis = The CCITT standard for 14,400 BPS operation. V42 = The CCITT standard for hardware error correction. V42.bis = The CCITT standard for hardware data compression. Now for some NON-STANDARD information that might prove useful in your travels: HST = A proprietery 9600, 14400, and 16800 connection scheme used ONLY by US Robotics. ZYXEL = A high-speed modem manufacturer that recently came out with a proprietery 16,800 connection scheme (and maybe 19.2 now, from what I've heard). Zyxels and USR's don't talk to each other at 16,800 (this will sound very familiar here in a bit). Zyxel modems *DO* also support the v.32 and v.32bis FidoNews 10-23 Page: 6 07 Jun 1993 standards. But don't think you will get a 16,800 connection to every other v.32bis modem in the world. You won't. You'll get a 14.4 connection. Now for some "speed-freak-mood-dampening": DON'T BE FOOLED by the advertised throughput of 38,400 bps for v.32 modems and 57,600 for v.32bis modems. You will never see file transfer rates that high, but you *CAN* talk to your modem at that speed. Here's a chart of what you should REALLY be expecting. Compressed files transferred via Zmodem with most bulletin boards: ("Plain" means no MNP or V42) Type of modem: 1200 2400 v.32 v.32bis +------------------------------+ Characters per / Plain | 112 234 940 1300 | second (CPS) \ MNP/V42 | 130 270 1100 1650 | +------------------------------+ Bits per / Plain | 1120 2340 9400 13000 | second (BPS) \ MNP/V42 | 1300 2700 11100 16500 | +------------------------------+ ...so, when you see those advertisements for "38,400" and "57,600", don't believe it. You can talk to your communications port at that speed, but you won't see that kind of throughput on your file transfers except in VERY, VERY unusual conditions. How unusual, you ask? ALL of the following has to be true: - You transfer nothing but text and/or compressible files, - You hook up with a modem that has the same computer-to-modem speed that you are using (38,400 or 57,600), - The file being transferred is VERY compressible, - You have a crystal clear phone line, and - You both have v.42bis compression enabled. Bottom lines: v.32 (9600) modems max out at about 1,100 cps. v.32bis (14400) modems max out at about 1,650 cps. Under ideal conditions, you might squeak a few more characters per second out of them, but on a continual basis you will speeds like these on relatively clean lines. That's all there is to it. You *CAN* set your modem to report "CONNECT 38400" or "CONNECT 57600", but don't believe it. That is the "computer to modem" speed, not the actual connect rate. I recommend you set your end to report the true modem-to-modem connect rate to avoid confusion (see the end of this article). Or, to look at it another way that might make more sense, v.32 means around 60,000 bytes per minute, while v.32bis means just a hair shy of 100,000 bytes per minute. So, when you see a file FidoNews 10-23 Page: 7 07 Jun 1993 that is 1 megabyte in size, it takes about 10 minutes to transfer it at v.32bis. Let's move on... -------------------------------------------- So how did we get here? The only way to start to talk about this is via a history lesson as I see it. Just some observations: When you bought a 1200 or 2400 BPS modem, you stood a pretty good chance of connecting 1200 or 2400 with almost any other modem out there that said it supported the same speed. Not so when we moved to 9600, even worse when we went faster, thanks to the different modem manufacturers ignoring the international standards. Why, you ask? Many moons ago, the CCITT v.32 standard was not in use by anybody, as it was deemed to be too expensive to realistically build hardware to support the as-yet-unused international standard. (All of that has changed now). Modem manufacturers retaliated by building their own proprietery 9600 connection schemes, and the next thing you knew there were modems all over the place that wouldn't talk to any other brand at 9600 and beyond. (We still have a bit of this going on, with Zyxel and USR). If you bought a CompuCom 9600, you had to find another CompuCom 9600 to connect to if you wanted 9600 BPS operation. Etc. etc... this carries over today - if you buy a straight US Robotics HST modem, you must find another US Robotics HST (or Dual Standard) modem to connect with if you want to connect above 2400 bits per second. Quite a letdown to buy an expensive high-speed modem only to travel at 2400! Zyxel's 16,800 protocol is not compatible with US Robotics' HST implementation of the same speed, so if you want to travel at 16800 with a Zyxel, you have to find another Zyxel to connect to. (Yes, again, the Zyxels *DO* drop to 14.4 and below using v.32/v.32bis). Isn't this fun? Here's why it came down that way: As connect speeds increased, so did errors in data transmission. Anyone who has ever used a "standard" modem of the 1200 or 2400 BPS variety can verify that you do occasionally experience line noise, which shows up as a burst of incomprehensible characters on your terminal. A 2400 BPS modem does not use NEARLY the bandwidth that high-speed modems do, so you can imagine what happens with one of these when you experience line errors. That's why "error correction" and "data compression" are built into the hardware on most of these things. We'll talk about THOSE in a bit here. Before all settled down, the one that rose to the top of the heap in the BBS world was USRobotics, with their proprietery HST modulation scheme, which is still in use on MANY bulletin boards today. USR is still widely accepted in the BBS community as the leading FidoNews 10-23 Page: 8 07 Jun 1993 manufacturer for BBS-compatible modems, but there is a price to pay (more on this in a minute). USR has since upped their proprietery HST protocol to 14,400 bps, and most recently 16,800. Problem is, you NEED a USRobotics modem to talk to them at that speed. USR does manufacture the "ultimate BBS modem" from my viewpoint, and that is the USRobotics Courier HST Dual Standard, supporting both their HST line, as well as the CCITT v.32 and v.32bis standards. With one of these modems, you can connect to virtually any bulletin board in the country at 9600 and beyond. Perfection has a price, however. The new Dual Standards are retailing for over $1,000 apiece (although they can be had for $700 or so thru direct channels). A little pricey from my standpoint. ----- Which brings us back to v.32 and v.32bis. These are the accepted international standards for high-speed modems, and they are only just recently becoming widespread, and supported by MANY modem manufacturers. Virtually every modem manufacturer EXCEPT USR and Zyxel have devoted their high-speed lines strictly to the CCITT v.32 and v.32bis modulation schemes. THE HIGHEST STANDARD SPEED MODEM THAT YOU CAN BUY IS V32.BIS, WHICH MEANS UP TO 14,400 MODEM-TO-MODEM SPEED. PERIOD. There is a new protocol under development by the CCITT - and that is V.FAST. V.FAST will probably be the last standard, as that will completely max out what the phone lines in this country are capable of. If the modem you are considering says it will be upgradable to V.FAST when that standard matures, you may be able to upgrade painlessly. You will pay a price for this promised upgradability. Now, back to error correction and data compression. You're likely to have heard terms like MNP levels 1-5, v.42, and v.42bis. Strangely enough, NOT ALL HIGH-SPEED MODEMS SUPPORT THESE. I have seen some low-end v.32 modems that will connect at 9600 BPS, but with no error correction, meaning that your high-speed connections will be unreliable at best. Let's talk about these terms for a bit: MNP = Microcom Networking Protocol. There didn't used to be any standard for error correction/compression, and Microcom's implementation gained wide acceptance pretty quickly. Most modems that support error correction support MNP. There are several "levels" of MNP built into many modems, even more than I'm going to bring up here, but here's what a few of the more common methods mean (briefly): Levels 1 through 4 = Error correction. The modems negotiate to the highest-supported level on both ends, and errors in transmission are "filtered" before they get to the remote terminal. FidoNews 10-23 Page: 9 07 Jun 1993 Level 5 = Data compression. If "compression" is turned on on BOTH ENDS of the connection, and both modems support MNP-5, the modems will negotiate to this type of connection. Theoretically, this can increase throughput on file transfers. But, in reality, 90% of the files you transfer are already compressed (ZIP, ARJ, LZH, etc.), so the overhead of this protocol will actually slow you down. V.42 = The accepted international standard for error correction. It is generally felt that v42 hookups connect quicker and more efficiently than their MNP-4 equivalents. Most modems supporting V42 will "fall back" to MNP-4 if a v42 connection couldn't be made, and to no error correction if both fail. V.42bis = ...and here's the international standard for data compression. It is generally felt that v.42bis performs better than MNP-5, especially on noisy lines. Most modems supporting v.42bis will "fall back" to MNP-5 if a v42.bis connection couldn't be made. v.42bis is more efficient than MNP-5, and you will usually see higher throughput than with MNP-5. Things to remember: - You're always limited by the phone lines in your area. If you get static on the line when you make a voice call, you can amplify that several times over when you make a high-speed connection. 9600 and 14400 use just about all of the available bandwidth. When V.FAST comes out, the bandwith will be completely used up. - ERROR CORRECTION is a must. DATA COMPRESSION really isn't, although one tends to come with the other on most modems these days, and there are quite a few people who will tell you that you NEED v.42bis. I have always seen the best transfer speeds with error correction on, and MNP5 data compression off. The one exception is if you transfer a lot of text and/or data files that are NOT already compressed. In that case, v.42bis data compression really can speed up your transfers a bit. - Many of these modems come with fax capability. If you think you might want to be able to send and receive faxes right from your home PC, go ahead and get it. The cost to include fax is minimal: it only adds about $20.00 to the cost of the modem (mostly for the fax software), thanks to the Rockwell and AT&T v.32bis chipsets, which have fax capability built in. - Most any 9600 BPS modem (including the HST) will connect with any other high-speed modem at 2400 and below. <<----- ~~~~~~~~~~~~~~~~~ - Zyxel's 16,800 BPS modem will connect 16,800 only with another Zyxel. These modems WILL fall back to 14,400 and below, since they do follow the v.32 and v.32bis standards. FidoNews 10-23 Page: 10 07 Jun 1993 - USRobotics' HST, like any other modem using a proprietery scheme, will connect 9600 and beyond only to another USRobotics HST or Dual Standard modem. - USRobotics' HST Dual Standard (the pricey one) will connect 9600 and beyond with both their own HST's, as well as v.32 and v.32bis modems (which is just about the whole high-speed market). This works the other way, too, of course. - Any modem supporting v.32 should connect 9600 to any other modem supporting v.32 (from various manufacturers). - Any modem supporting v.32bis should connect 14400 with any other modem supporting v.32bis, as well as 9600 with v.32 modems. - v.32 has one "fallback" speed: 4800 BPS, before those modems resort to 2400 for communications on "dirty" lines. - v.32bis has two additional fallback speeds: 12,000 and 7,200. v.32bis modems will also use the v.32 fallback speeds of 9,600 and 4,800, if applicable. ------------------------------------------------------ My advice to you: Stay away from oddball 9600+ modems that won't talk to anything but other modems from the same manufacturer above 2400 bps. USR's HST has a strong foothold in the BBS market, but that foothold is dwindling. v.32 and v.32bis are here and now, and you have MANY different modem brands to choose from (commercial on-line services are already going to v.32). I'm not knocking Zyxel - I've heard good things about them. Just don't expect to get a 16.8 or 19.2 connection to everybody. You won't. Go v.32bis at 14,400. Real-world pricing for low-end v.32bis has dipped all the way down to $200 apiece (even lower on some internal models) from several different manufacturers (Zoom and Boca, to name but a couple). The price difference between v.32 and v.32bis is minimal, but you gain 500 characters per second on your file transfers. (That's like having an extra 4,800 bps modem built-in, to put it in perspective). Talk to your high speed modem FASTER than the actual connect rate - this will get you optimum file transfer speeds. I suggest either 19200 or 38400 - you won't see much if any difference in throughput between these two on compressed files. Your call. Whatever your system can handle. If you have a large wallet, get a USRobotics HST Dual Standard (*NOT* the cheaper HST model). They are very good, reliable modems, and most communications & BBS software have setup info for them. They were simply too expensive to be a practical option on this end. FidoNews 10-23 Page: 11 07 Jun 1993 Make sure your system can handle the speed before you buy. You should have at LEAST an 8-10mhz machine (preferably a 286 or better), and it would be nice to have a 16550 UART on your serial port. If you're in a multi-tasking environment, or you do find yourself dropping characters, you'll need a 16550 UART (which has a small built-in buffer to help out with this problem). Insist on error correction of some type, either MNP-4 or v.42. Otherwise, the line noise is likely to make life miserable for you. You'll likely also receive data compression with your modem, since one tends to come with the other. If you aren't transferring text files, turn off data compression (especially MNP-5) for maximum throughput on compressed files like .ZIP, .ARJ, etc. There are people who will tell you that you'll do BETTER with v.42bis enabled, but that hasn't been the case in my experience thus far. BE WARY OF USED v.32bis MODEMS FOR AWHILE. Rockwell put out a bad set of the v.32bis chipsets a while back, and modem manufacturers were putting out updated ROMs for these modems at a bizzare rate. You want to be able to return the modem if it's broken. ------------------------------------------------------ Recommended configuration settings for Rockwell chipset v.32bis modems, such as Zoom, Boca, generic brands, etc. etc: Set your communications program as follows: - 19200 or 38400 port speed, and leave it there. You can connect from 300 bps all the way up to 14400 with that port speed, believe it or not. - use CTS/RTS handshaking (not XON/XOFF) - Don't match connect rate (leave modem at 19200 or 38400 after connect). - Set your default file transfer protocol to something other than Xmodem!!! Zmodem is recommended, YmodemG is better yet on REAL clean lines and with a good communications port, but a single error in transmission and you will lose the whole file transfer. That's why I recommend Zmodem. Ymodem (or 1K-Xmodem) is pretty good, too, but Zmodem is better. - Set your initialization string to ATZ [ENTER]. That's really all you need, after you set up your modem. Now set up your modem. AT&F (reset to factory defaults) AT&C1&D2S95=3S38=2S11=55S37=11&W (standard stuff - look at FidoNews 10-23 Page: 12 07 Jun 1993 your modem manual to see what each of these do). If you don't like annoying high pitched screeching and howling in your ear: ATM0&W Then, to set the modem to your phone line: AT%E1\E1N0S37=9 ATDTxxxxxxx (Replace "xxxxxxx" with the phone number of a local v.32 or v.32bis bulletin board). After all the screeching and howling, you ought to get a 9600 connection. This first connection might be a little strange - the modem is training itself to the phone line. After you have made a successful connection, log off the BBS, and issue the command: ATZ This will reset the modem to your defaults, and will allow you to connect up to 14400 on subsequent calls. From here on you just dial out with ATDT, or from within your dialing directory of your communications program. "Your experiences may vary". I have set up two Zoom v.32bis and three Boca v.32bis modems this way, and had no trouble at all. You have a modem manual, if you want to dink with any of the settings later. So those are my opinions, worth what you paid for 'em. ---------------------------------------------------------------------- New Echo: The Complaint Department Join The Complaint Department and lower your stress level: COMPLAINT_DEPT by Alisanne Fleitman, Moderator COMPLAINT_DEPT is an echo for moaning and groaning and general all-purpose complaining. Tell everyone how awful your boss is, how your Mother-In-Law is driving you crazy, what your spouse said to infuriate you, how your parents never appreciate what a great kid they have or how your teachers are out to get you. This is NOT an echo for solving problems or political discussions. The rules are simple. You MAY NOT use your real name. Only aliases are allowed. This is for your protection! Absolutely no bad language. No profanity or obscenity. Any replies to other posters complaints should be limited to sympathizing with their miseries. Suggestions: "You poor dear. How do you stand it? All (wives,husbands,parents, teachers) are no good." FidoNews 10-23 Page: 13 07 Jun 1993 Contact Alisanne Fleitman at Fidonet: 1:2605/709, AdaNet: 94:9080/1, GlobalNet: 51:1100/7 or CIS: 76367,2557 for further information. ------- ---------------------------------------------------------------------- Time to do away with Zone Mail Hour by Kevin Eastman (PVT) 1:3402/7 or (CM) 1:3402/25 Zone Mail Hour - A good idea whose time has PASSED As any Fidonet system should know, and according to Policy 4, Zone Mail Hour is "Supposedly" the heart of Fidonet. Well, this may have been so when Fidonet only had a few systems, but now that Fidonet has grown, Zone Mail Hour is more of an annoyance than a help. Lets take a look at what Policy 4 has to say about Zone Mail Hour. 2.1.8 Exclusivity of Zone Mail Hour Zone Mail Hour is the heart of FidoNet, as this is when network mail is passed between systems. - Well, considering that the majority of systems currently in Fidonet - are considered CM, meaning they can recieve mail 24 hours a day, the - above statement is redundant. 1. This time is exclusively reserved for netmail. Echomail should not be transferred during ZMH. - If one tried sending a netmail message to a system that has echomail - on hold for them, with the mailers out today, there is no way to - prevent recieving the echomail that is on hold. So, am I to understand - that if I do, then I am in violation of Policy. - I have found that whenever I have tried to send a netmail message - to a system, especially a busy one such as a Star or an RC, more often - than not, I have to try them outside of Zone Mail Hour, as, with all - the systems in Fidonet all trying to send netmail at the same time, - most people don't have a hope in you know what, of getting it through - during Zone Mail Hour anyway. User (BBS) access to a system is prohibited during ZMH. - I, like many other people out there, do not have a lot of money for - calling long distance to access a BBS. So, the only solution is to do - it when the phone companys rates are cheaper. Unfortunately, this is - also the time when everyone is trying to send their netmail and - echomail, so even without Zone Mail Hour, Users already have to - compete with the normal mail flow. We run our systems as a hobby for - ourselves and our users, including the ones calling long distance, and - to deny those long distance users access during that time set aside - for Zone Mail Hour is very annoying. As some systems are SO busy, FidoNews 10-23 Page: 14 07 Jun 1993 - I consider it accessively annoying to make users wait that one extra - hour to get on a system. Many phone systems charge on a per-call basis, regardless of whether a connect, no connect, or busy signal is encountered. - So????? That is a problem between the system operator and their phone - company. It has nothing to do with the operation of my, and the - majority of the other systems in Fidonet. As a wise person once said, - "The needs of the many outweigh the needs of the few, or the one." For this reason, any activity other than normal network mail processing that ties up a system during ZMH is considered annoying behavior. - So you have a choice, you can be guilty of annoying behaviour for - processing mail only, or you can be guilty of annoying behaviour for - allowing the transferral of echomail and allowing users on your system - during that one hour. Personally, I think the users are more - important, as, without them, whats the point of running a continuous - system. ---------------------------------------------------------------------- New Echo: Bartering: North and Central New Jersey A New Echo offered for Bartering Only: BARTER_NORTH+CENTRAL_NJ by Alisanne Fleitman, Moderator Are there goods or services you need but can't afford to pay cash to purchase? Is there something you can offer in exchange instead of cash? If you are in the North or Central New Jersey area - or can provide your service or goods there - use this echo to post both your offering and your needs. THIS IS NOT A FOR-SALE ECHO. Only bartering. No cash sales. All arrangements are between individuals. The moderator takes no responsbility and assumes no liability. Contact Alisanne Fleitman at Fidonet: 1:2605/709, AdaNet: 94:9080/1, GlobalNet: 51:1100/7 or CIS: 76367,2557 for further information. ------- ---------------------------------------------------------------------- A Star Trek computer network by Rick Giguere, Fidonet 1:101/165 Treknet (tm) is a fan-run computer network covering every aspect of the Star Trek universe and other science fiction and fantasy topics. There are no fees for membership in Treknet (tm), and since Treknet is an independent organization, there is no obligation to belong to ANY club or organization. The ONLY requirements are an interest in Star Trek and science fiction, and an FTN-compatible mail system. FidoNews 10-23 Page: 15 07 Jun 1993 We are in our fourth year of operation, and feature echomail conferences covering just about every aspect of the Star Trek universe, whether it be a race such as Vulcans, Romulans or Bajorans; or a department such as engineering, communications or security. In addition, we offer conferences helping Fans locate clubs near them, announcing and discussing conventions, and offer support services to a growing number of Fan Organizations. Topics you'll find on Treknet (tm) include such Treknological ones as Warp Drive limitations and technology, the discussion of various ship classes and their design and capabilities, security practices, Starfleet Intelligence operations, and more. More "mundane" topics include how to publish a newsletter, fanzine or other publication, how to run a con, finding crash space for an out-of-town con, finding a fan club near you, and more! We currently have members or representatives of many different Star Trek fan clubs online with Treknet (tm), including KAG, KLAW, Starfleet Marines, Starfleet International, The Federation, Starfleet Command, Starfleet Rangers, Star Trek Welcommittee, the BSTA and many, many local groups! We currently have over 150 member systems throughout the world, with hubs in most major US and Canadian areas, and even some international ones! For more information FReq "Treknet.ZIP" from 1:203/57 or 1:101/165 .... or contact Rob Lerman at 1:203/57 or Rick Giguere at 1:101/165. Rick Giguere, Co-Vice International Coordinator, Treknet (tm) SysOp, StarBase: Boston (sm) TBBS 1-617-739-0210 ---------------------------------------------------------------------- ======================================================================== Fidonews Information ======================================================================== ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ---------------- Editors: Sylvia Maxwell, Donald Tees, Tim Pozar Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello, Tom Jennings IMPORTANT NOTE: The FidoNet address of the FidoNews BBS has been changed!!! Please make a note of this. "FidoNews" BBS FidoNet 1:1/23 BBS +1-519-570-4176, 300/1200/2400/14200/V.32bis/HST(DS) Internet addresses: Don & Sylvia (submission address) editor@exlibris.tdkcs.waterloo.on.ca FidoNews 10-23 Page: 16 07 Jun 1993 Sylvia -- max@exlibris.tdkcs.waterloo.on.ca Donald -- donald@exlibris.tdkcs.waterloo.on.ca Tim -- pozar@kumr.lns.com (Postal Service mailing address) (have extreme patience) FidoNews 172 Duke St. E. Kitchener, Ontario Canada N2H 1A7 Published weekly by and for the members of the FidoNet international amateur electronic mail system. It is a compilation of individual articles contributed by their authors or their authorized agents. The contribution of articles to this compilation does not diminish the rights of the authors. Opinions expressed in these articles are those of the authors and not necessarily those of FidoNews. Authors retain copyright on individual works; otherwise FidoNews is copyright 1993 Sylvia Maxwell. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact the original authors, or FidoNews (we're easy). OBTAINING COPIES: The-most-recent-issue-ONLY of FidoNews in electronic form may be obtained from the FidoNews BBS via manual download or Wazoo FileRequest, or from various sites in the FidoNet and Internet. PRINTED COPIES may be obtained from Fido Software for $10.00US each PostPaid First Class within North America, or $13.00US elsewhere, mailed Air Mail. (US funds drawn upon a US bank only.) BACK ISSUES: Available from FidoNet nodes 1:102/138, 1:216/21, 1:125/1212, (and probably others), via filerequest or download (consult a recent nodelist for phone numbers). A very nice index to the Tables of Contents to all FidoNews volumes can be filerequested from 1:396/1 or 1:216/21. The name(s) to request are FNEWSxTC.ZIP, where 'x' is the volume number; 1=1984, 2=1985... through 8=1991. INTERNET USERS: FidoNews is available via FTP from ftp.ieee.org, in directory ~ftp/pub/fidonet/fidonews. If you have questions regarding FidoNet, please direct them to deitch@gisatl.fidonet.org, not the FidoNews BBS. (Be kind and patient; David Deitch is generously volunteering to handle FidoNet/Internet questions.) SUBMISSIONS: You are encouraged to submit articles for publication in FidoNews. Article submission requirements are contained in the file ARTSPEC.DOC, available from the FidoNews BBS, or Wazoo filerequestable from 1:1/23 as file "ARTSPEC.DOC". Please read it. "Fido", "FidoNet" and the dog-with-diskette are U.S. registered trademarks of Tom Jennings, and are used with permission. FidoNews 10-23 Page: 17 07 Jun 1993 Asked what he thought of Western civilization, M.K. Gandhi said, "I think it would be an excellent idea". -- END ----------------------------------------------------------------------